Typically, an application programming interface (API) is understood as a particular set of rules and specifications that a software program can follow in order to access and make use of the services and resources provided by another particular software program that implements that API. The API serves as an interface between different software programs and facilitates their interaction, similar to the way that the user interface facilitates interaction between humans and computers. APIs are often used in a client-server architecture, to enable direct interfacing between a client device (or “client”) and a server device (or “server”), e.g., over a network such as the Internet. In such architecture, API calls are typically sent back and forth between a client and a server in the form of requests (from the client device) and responses (from the server devices).
As a matter of course, different companies, which provide various different services, functionalities, and/or information, design and deploy their own unique APIs having their own unique data structures, etc. Furthermore, there are many different types of API architectures (e.g., RESTful, SOAP, XML-RPC, etc.), which may be implemented in a variety of different situations, such as Public APIs (available to developers), Private APIs (unavailable to developers), Internal APIs, third party APIs, and may relate to any number of specific applications such as, for example, mobile applications, web application, internet-of-things (IOT) applications and technologies, etc. APIs may also be configured for a variety of common data protocols (e.g., (JSON, XML, YAML, etc.), over a variety of communication protocols (Ethernet, IP, TCP, UDP, HTTP, HTTPS, HTTP/2, WebSocket, etc.). With so many variables, each unique API will have its own unique vulnerabilities to attack by hackers, etc.
Most APIs are vulnerable to advanced persistent threat (APT) attacks, zero day attacks, and other similar attacks which look to exploit the vulnerabilities of a company's API. Moreover, developers put limited attention to security, and continued development of an API requires careful review of implemented legacy security systems and either updates for security assurance or using the developer's own code for security assurance and validity. The current state of the art creates opportunities for exploiting vulnerabilities and enhances security challenges.
Generally, when an attacker wants to attack an API and details regarding that API are not publically available, there are a number of steps/processes often taken to learn about the API: (1) Reconnaissance—“sniffing” or otherwise listening to the traffic back and forth between the client and the server in order to document the structure, communication protocols, etc., of the API and reverse-engineering the information to get a complete picture of the API; (2) Generate illegal requests—once all the API details are known, the attacker can begin sending illegal requests directly to the backend of the server (rather than following the set API protocols, which typically only allow forward-facing communication, e.g., via a mobile application). These calls can include malicious code which can change parameters, add invalid inputs, etc., and may eventually expose a vulnerability of the API; and (3) Attack—upon find a vulnerability, implementing an attack on the server via the API.
Presently available cyber-security systems do not resolve these fundamental flaws, as they account only for “known attacks”, e.g., attacks that have identifiable signatures that can be monitored for and blocked, for example monitoring calls for a specific term, etc. However, unknown vulnerabilities, which are specific to each API, cannot be accounted for using these methods. Instead, a customized solution that is tailored to each unique API is required.